Method, system, and apparatus for registration processing

ABSTRACT

A registration processing method and an apparatus are disclosed herein to enable the network to distinguish between different registration processing types. The method includes: identifying, by a user equipment, UE, a registration type when registering into a network; reporting, by the UE, a registration processing type information corresponding to the identified registration type to a network-side network element during registering into the network. The UE reports the registration processing type information to the network in the process of registering into the network, and therefore, the network distinguishes between different registration processing types accordingly.

CROSS-REFERENCE TO RELATED APPLICATIONS

More than one reissue application has been filed for reissue of U.S.Pat. No. 8,787,314. This application is an application for reissue ofU.S. Pat. No. 8,787,314, and is a continuation of U.S. patentapplication Ser. No. 15/216,469, filed on Jul. 21, 2016, which is alsoan application for reissue of U.S. Pat. No. 8,787,314 (now RE 48,067).The application resulting in U.S. Pat. No. 8,787,314 was filed on Aug.3, 2011 as U.S. patent application Ser. No. 13,197,537, which is acontinuation of U.S. patent application Ser. No. 12/581,575, filed onMay 8, 2008, which is a continuation of International Application No.PCT/CN2008/070909, filed on May 8, 2008. The International Applicationclaims priority to Chinese Patent Application No. 200710104400.7, filedon May 11, 2007, Chinese Patent Application No. 200710181758.X, filed onOct. 24, 2007, Chinese Patent Application No. 200710165540.5, filed onNov. 2, 2007 and Chinese Patent Application No. 200810085729.8, filed onMar. 13, 2008. The afore-mentioned patent applications are herebyincorporated by reference in their entireties.

FIELD OF THE DISCLOSURE

The present disclosure relates to the communication field, and inparticular, to a registration processing method, a handover processingmethod, a system, and an apparatus.

BACKGROUND

In order to enhance the competitiveness of the future networks, theThird Generation Partnership Project (3GPP) is researching a new evolvednetwork. A requirement of the evolved network is to implement handoverbetween a 3GPP access system (such as GERAN, UTRAN, or E-UTRAN) and anon-3GPP access system (such as a WLAN or WiMax). In the existingprotocol, the handover procedure is implemented via Attach or TrackingArea Update (TAU) procedure by the UE in a new access system.

In the process of developing the present disclosure, the inventor findsthat the processing mechanism of an Attach or TAU process caused byhandover differs sharply from the processing mechanism of a normalAttach/TAU process: In a normal Attach process, the network needs todelete all bearers previously created by the user, create a defaultbearer between the UE and the Packet Data Network Gateway (PDN GW), andregister the PDN GW address used by the UE into a Home Subscriber Server(HSS); but in an Attach process caused by handover, the network needs tore-create all bearers previously created by the user. In the normal TAUprocess, the network does not handle the bearers of the user, but in theTAU process caused by handover, the network needs to re-create allbearers previously created by the user.

In the normal handover between a 3GPP system and a non-3GPP system, theUE is disconnected from the source Access Network (AN) first, and thenthe UE accesses the target access network through an Attach process.Consequently, the interruption of the UE service is long, whichinfluence the service experience of the user. Therefore, an optimizedhandover mechanism is adopted for handover between an Evolved UMTSTerrestrial Radio Access Network (E-UTRAN) network and a High RatePacket Data (HRPD) access networks in Code Division Multiple Access(CDMA) network. In the optimized handover mechanism, the user plane pathhands over to the target access network first before the UE hands overto the target access network (namely, while the UE is in the sourceaccess network).

In the process of developing the present disclosure, the inventor findsthat the UE may hand over from an HRPD network to an E-UTRAN network ineither idle state or active state. When the UE performs handover in anactive state, the access network may be notified to create the bearer onthe access network side in the handover process in order to speed upservice recovery time after the UE hands over to the target accessnetwork. However, in the idle state, the UE runs no service and is notsensitive to handover delay. Creating bearers on the access network sidewhen the UE is idle is a waste of the access network resources. In apre-handover mechanism, once the UE handover fails, the UE needs tonotify the PDN GW to switch the downlink path back to the source accessnetwork. Therefore, the pre-handover mechanism makes the system morecomplicated.

SUMMARY

A registration processing method, a handover processing method, asystem, and an apparatus are disclosed in an embodiment of the presentdisclosure to enable the network to distinguish between different accessprocessing types.

A registration processing method is disclosed in an embodiment of thepresent disclosure. The method includes: identifying, by a userequipment, UE, a registration type when registering into a network;reporting, by the UE, a registration processing type informationcorresponding to the identified registration type to a network-sidenetwork element during registering into the network.

A UE is disclosed in an embodiment of the present disclosure. The UEincludes an identifying unit and a reporting unit. The identifying unit,configured to identify a registration type when the UE initiates theregistration; a registration initiating unit, configured to initiateregistration, and send a registration triggering signal. The reportingunit is configured to receive the registration triggering signal fromthe registration initiating unit, and report processing type informationduring registering the UE into the network, where the processing typeinformation corresponds to the registration type identified by theidentifying unit.

In the embodiments of the present disclosure, the UE reports theregistration processing type information to the network duringregistering into the network, and therefore, the network distinguishesbetween different registration processing types accordingly.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows system architecture of an evolved network in an embodimentof the present disclosure;

FIG. 2 shows system architecture of optimized handover between an HRPDaccess system and an E-UTRAN access system in an embodiment of thepresent disclosure;

FIG. 3 is a flowchart of a method in an embodiment of the presentdisclosure;

FIG. 4 shows a structure of a system in an embodiment of the presentdisclosure;

FIG. 5 shows a structure of a UE in an embodiment of the presentdisclosure;

FIG. 6 shows a structure of a network-side network element in anembodiment of the present disclosure.

FIG. 7 is a flowchart of the first embodiment of the present disclosure;

FIG. 8 is a flowchart of the second embodiment of the presentdisclosure;

FIG. 9 is a flowchart of the third embodiment of the present disclosure;

FIG. 10 is a flowchart of the fourth embodiment of the presentdisclosure;

FIG. 11 is a flowchart of the fifth embodiment of the presentdisclosure;

FIG. 12 is a flowchart of the sixth embodiment of the presentdisclosure;

FIG. 13 is a flowchart of the seventh embodiment of the presentdisclosure;

FIG. 14 is a flowchart of the eighth embodiment of the presentdisclosure;

FIG. 15 is a flowchart of the ninth embodiment of the presentdisclosure;

FIG. 16 is a flowchart of the 10^(th) embodiment of the presentdisclosure;

FIG. 17 is a flowchart of the 11^(th) embodiment of the presentdisclosure;

FIG. 18 is a flowchart of the 12^(th) embodiment of the presentdisclosure; and

FIG. 19 is a flowchart of the 13^(th) embodiment of the presentdisclosure.

DETAILED DESCRIPTION

FIG. 1 shows system architecture of an evolved network in an embodimentof the present disclosure. The architecture includes:

an E-UTRAN, configured to implement all radio-related functions in theevolved network;

a Mobility Management Entity (MME), responsible for control planemobility management, including user context and Mobility statemanagement, and allocation of temporary mobile subscriber identifiers;

a serving gateway (GW), which is a user plane anchor between 3GPP accesssystems and is configured to terminate the interface to the E-UTRAN;

a PDN GW, which is a user plane anchor between a 3GPP access system anda non-3GPP access system, and is configured to terminate the interfaceto the external Packet Data Network (PDN);

a Policy and Charging Rule Function (PCRF), responsible for policycontrol decision and flow based charging control;

an HSS, configured to store subscriber data;

a UMTS Terrestrial Radio Access Network (UTRAN) and a GSM/EDGE RadioAccess Network (GERAN), configured to implement all radio-relatedfunctions in the existing GPRS/UMTS network;

a Serving GPRS Supporting Node (SGSN), configured to implement routeforwarding, mobility management, session management, and subscriber datastorage in a GPRS/UMTS network;

a non-3GPP IP access system, an access network defined by a non-3GPPorganization, for example, Wireless Local Area Network (WLAN), andWorldwide Interoperability for Microwave Access (WiMAX); and

an AAA server, configured to perform access authentication,authorization and accounting for the UE.

The foregoing architecture does not mean the ultimate SystemArchitecture Evolution (SAE), and the ultimate architecture may differfrom the foregoing architecture, as is not limited by the presentdisclosure.

FIG. 2 shows system architecture of optimized handover between an HRPDaccess system and an E-UTRAN access system in an embodiment of thepresent disclosure. An S101 interface is added between the MME and theHRPD Access Network (HRPD AN) which is responsible for mobilitymanagement and radio resource management in the HRPD network. Thisinterface transmits the signaling between the MME and the HRPD AN. APacket Data Serving Node (PDSN) is a user plane processing networkelement in an HRPD network, and performs user plane processing in theHRPD network.

The registration processing method, the handover processing method, thesystem, and the apparatus disclosed herein are based on the foregoingtwo types of system architecture, and are elaborated below:

In order to enable the network to distinguish between differentregistration processing types, a registration processing method isdisclosed in an embodiment of the present disclosure. As illustrated inFIG. 3 , the method includes the following steps:

S1. The network receives information about the processing type ofregistering the UE into the network, where the information is reportedby the UE during the registration.

Before this step, the UE may identify the type of the registration whenregistering into the network. The UE reports the information about theprocessing type corresponding to the identified registration type to thenetwork during registering into the network.

S2. The network identifies the processing type of the registrationaccording to the information about the processing type.

Another registration processing method is disclosed in an embodiment ofthe present disclosure. The method includes: The network receivesinformation about a processing type of registering a UE, where theinformation is reported by an HSS or an AAA server; and the networkidentifies the processing type of the registration according to theinformation about the processing type.

A registration processing system is disclosed in an embodiment of thepresent disclosure. As illustrated in FIG. 4 , the system includes a UEand a network.

The UE is configured to report information about the processing type ofregistering the UE into a network during the registration. The UEidentifies the processing type of the registration during registeringinto the network and then reports the registration processing typeinformation.

The network is configured to identify the processing type of theregistration according to the received registration processing typeinformation reported by the UE. Specifically, the network-side MME (inan evolved network), SGSN (in a 2G/3G network), or non-3GPP GW (in anon-3GPP network) identifies the processing type information reported bythe UE.

A UE is disclosed in an embodiment of the present disclosure. Asillustrated in FIG. 5 , the UE includes:

an identifying unit, configured to identify the type of registrationwhen the UE initiates the registration;

a registration initiating unit, configured to initiate registration, andsend a registration triggering signal; and

a reporting unit, configured to receive the registration triggeringsignal from the registration initiating unit, and report the processingtype information during registering the UE into the network, where theprocessing type information corresponds to the registration typeidentified by the identifying unit. The reporting modes include but arenot limited to: The reporting unit includes the processing typeinformation in an information element (IE) of an Attach Request message;or the reporting unit includes the processing type information in an IEof a TAU request message; or the reporting unit includes the processingtype information in an IE of a Routing Area Update (RAU) requestmessage; or the reporting unit includes the processing type informationin an IE of an Access Request message; or the reporting unit includesthe processing type information in an IE of an Access Authenticationmessage or an Authentication message; or the reporting unit includes theprocessing type information in an IE of an Internet Key ExchangeProtocol Version 2 (IKEv2) or IP Security Protocol Security Association(IPsec SA) Setup request message.

The detailed reporting procedure of the reporting unit is: the reportingunit sends different Attach Request messages to the network based ondifferent registration types; or the reporting unit sends different TAUrequest messages to the network based on different registration types;or the reporting unit sends different RAU request messages to thenetwork based on different registration types; or the reporting unitsends different Access Request messages to the network based ondifferent registration types.

A network-side network element is disclosed in an embodiment of thepresent disclosure. The network element is an MME (evolved network),SGSN (2G/3G network), or non-3GPP gateway (non-3GPP network). Asillustrated in FIG. 6 , the network element includes an obtaining unitand an identifying unit.

The obtaining unit is configured to obtain the registration processingtype information reported by the UE during registering the UE into thenetwork. Specifically, the obtained processing type information isreported by the UE, the HSS or the AAA server.

The identifying unit is configured to identify the processing type ofthe registration according to the processing type information obtainedby the obtaining unit.

The network element further includes a first processing unit, which isconfigured to initiate a network-initiate bearer create procedure tocreate the bearer resources for the UE after the identifying unitidentifies that the registration processing type is a handoverregistration processing type.

The network element further includes a second processing unit, which isconfigured to not initiate resource release procedure to release thesource access network resources after the identifying unit identifiesthat the registration processing type is an active-mode handoverregistration processing type.

The network element further includes a third processing unit, which isconfigured to initiate a procedure of creating a data forwarding tunnelbetween a network element of the target network and a network element ofthe source network after the identifying unit identifies that theregistration processing type is an active-mode handover registrationprocessing type.

The present disclosure is elaborated through several embodiments below:

Embodiment 1

When the UE sends a registration request message to the MME, the UEreports the registration processing type information to the MME. The MMEidentifies the processing type of the registration according to theinformation, and performs the corresponding procedure according toregistration processing type to complete the registration. The MMEreports the registration processing type to the HSS. For theregistration caused by handover, the network initiates a bearer creationprocedure to create resources in the 3GPP network used by the UE in thesource non-3GPP network. For initialization registration, if the HSSstores the PDN GW address used by the UE in the non-3GPP network, theHSS notifies the AAA server to cancel the UE registration in thenon-3GPP network. The AAA server notifies the non-3GPP network torelease the resource used by the UE. As illustrated in FIG. 7 , theprocess includes the following steps:

1. The UE accesses the non-3GPP AN through the non-3GPP GW and the PDNGW.

2. The non-3GPP network element sends a Handover Command (HO Command) tothe UE, notifying the UE to hand over to the evolved network; or the UEdiscovers the evolved network and decides to initiate handover.

3. Before initiating registration into the evolved network, the UEidentifies the type of the registration. Afterward, the UE sends aregistration request message to the MME, and reports the registrationprocessing type to the MME.

The registration processing type may be reported in one of the followingways:

(1) An Attach Type IE is added in the Attach Request message. Forexample, the values of the Attach Type IE are 0 and 1. The value “0”corresponds to Normal Attach (also known as Initial Attach), andindicates that the Attach Request message is a normal Attach Requestmessage (also known as initial Attach Request message); and the value“1” corresponds to Handover Attach, and indicates that the AttachRequest message is caused by handover. Alternatively, the UE adds anindication bit in the Attach Request message to indicate that the AttachRequest message is caused by handover. The original Attach Requestmessage indicates a normal Attach Request message (also known as initialAttach Request message). The indication bit may be:

(a) a Handover Indication IE;

(b) a Cause IE. The UE sets the Cause IE to “Attach due to Handover”; or

(c) an Attach Type IE. The UE sets this IE to “Handover Attach”.

(2) A new message is defined. For example, a new Handover Attach Requestmessage is defined. This message indicates an Attach Request messagecaused by handover. The old Attach Request message indicates a normalAttach Request message (also known as an initial Attach Requestmessage). In this way, the UE can send different Attach Request messagesto the network to indicate the corresponding registration processingtype information. Alternatively, a new message corresponding to thenormal Attach Request message (also known as initial Attach Requestmessage) is defined, and the original Attach Request message correspondsto the Attach Request message caused by handover. Alternatively, boththe Attach Request message caused by handover and the normal AttachRequest message (also known as initial Attach Request message) areredefined.

(3) An Update Type IE is added in the TAU request message. For example,the values of the Update Type IE are 0 and 1. The value “0” correspondsto Normal TAU (also known as Initial TAU), and indicates that the TAUrequest message is a normal TAU request message (also known as initialTAU request message); and the value “1” corresponds to Handover TAU, andindicates that the TAU request message is caused by handover.Alternatively, the UE adds an indication bit in the TAU request messageto indicate that the TAU request message is caused by handover. Theoriginal TAU request message indicates a normal TAU request message(also known as initial TAU request message). The indication bit may be:

(a) a Handover Indication IE;

(b) a Cause IE. The UE sets the Cause IE to “TAU due to Handover”; or

(c) an Update Type IE. The UE sets this IE to “Handover TAU”.

(4) A new message is defined. For example, a new Handover TAU Requestmessage is defined. This message indicates a TAU request message causedby handover. The old TAU request message indicates a normal TAU requestmessage (also known as an initial TAU request message). In this way, theUE can send different TAU request messages to the network to indicatethe corresponding registration processing type information.Alternatively, a new message corresponding to the normal TAU requestmessage (also known as initial TAU request message) is defined, and theoriginal TAU request message corresponds to the TAU request messagecaused by handover. Alternatively, both the TAU request message causedby handover and the normal TAU request message (also known as initialTAU request message) are redefined.

4. An authentication procedure is performed between the UE, the MME, andthe HSS to obtain the PDN GW address used by the UE. In this step, theMME may report the registration processing type of the UE to the HSS. Ifthe registration processing type is a handover processing type, the HSSmay provide the MME with the PDN GW address used by the UE in thenon-3GPP AN.

5. The MME sends an Update Location message to the HSS, and registersthe address of the MME into the HSS. In this step, the MME may reportthe registration processing type of the UE to the HSS.

6. The HSS inserts the subscriber data into the MME.

7. The HSS returns an Update Location Ack message to the MME. In thisstep, the HSS may provide the MME with the PDN GW address used by the UEin the non-3GPP AN.

In the UE registration process, if the HSS identifies the UEregistration processing type (for example, the HSS finds that it storesthe PDN GW address used by the UE in the non-3GPP AN, the HSS determinesthat the UE registration processing type is registration caused byhandover. Otherwise, the HSS determines that the UE registrationprocessing type is a normal registration processing type), the HSS addsan indication bit into the message to notify MME of the UE registrationprocessing type information. The indication bit may be:

a) a Handover Indication IE. If the UE registration processing type isregistration caused by handover, the HSS adds a Handover Indication IE.For a normal registration processing type, the HSS does not add this IE;

b) a Cause IE. For the registration caused by handover, the HSS sets theCause IE to “Update due to Handover Attach”. For normal registration,the HSS sets the Cause IE to “Update due to Initial Attach”, or does notadd the Cause IE; or

c) an Update Type IE. For the registration caused by handover, the HSSsets this IE to “Handover Attach”. For normal registration, the HSS setsthis IE to “Initial Attach”, or does not add this IE.

8. The MME identifies the processing type of the registration accordingto the registration processing type information reported by the UE orthe HSS.

Now the MME succeeds in distinguishing between different registrationprocessing types.

Further, if the processing type is normal registration, the MME performsthe normal registration procedure, and steps 11-18 are performed.

If the processing type is registration caused by handover, the MME sendsa Create Bearer Request message to the obtained PDN GW address,requesting the network to initiate bearer creation procedure. In thisway, the service used by the UE in the non-3GPP AN is re-created in thenew access system. The process proceeds to step 9.

9. If it is necessary to obtain the Policy and Charging Control (PCC)rules applied by the user from the PCRF, the PDN GW sends a Request PCCRules message to the PCRF to obtain the PCC rules applied by the user.The PCRF provides the PDN GW with the PCC rules applied by the user.

10. The PDN GW initiates a network-initiate bearer creation procedure tocreate the bearer of the user, and then the process proceeds to step 18.

11. If the UE registration processing type is normal registration andthe HSS stores the registered PDN GW addresses, and if such PDN GWaddresses are the PDN GW addresses used by the UE when the UE accessesthe non-3GPP AN and are registered into the HSS through the AAA server,the HSS sends a Cancel Register message to the AAA server, requesting tocancel the UE registration in the non-3GPP AN. The AAA server returns aCancel Register Ack message to the HSS.

12. The AAA server sends a Cancel Register message to the PDN GW,requesting to cancel the UE registration in the non-3GPP AN. The PDN GWreturns a Cancel Register Ack message to the AAA server.

13. If the interface protocol between the PDN GW and the non-3GPP GW isa Proxy Mobile Internet Protocol (PMIP), the PDN GW sends a BindingRevocation Indication message to the non-3GPP GW to cancel the PMIPbinding between the non-3GPP GW and the PDN GW. The non-3GPP GW returnsa Binding Revocation Acknowledge message to the PDN GW.

14. The AAA server may also send a Session Abort message to the non-3GPPGW. The non-3GPP GW returns a Session Abort Ack message to the AAAserver.

15. After receiving the Binding Revocation Indication message or theSession Abort message, the non-3GPP GW initiates a resource releaseprocedure to release the resource used by the UE in the non-3GPP AN.

16. If the registration processing type of the UE is normalregistration, the MME initiates a default bearer creation procedure tocreate a default bearer between the UE and the PDN GW.

17. The MME registers the PDN GW address used by the UE into the HSS.This operation may also be handled through a location update procedure.The MME sends an Update Location message including the PDN GW address tothe HSS.

18. The MME returns an Attach Accept message or a TAU Accept message tothe UE.

Embodiment 2

The foregoing mechanism is also applicable to a 2G system and a 3Gsystem. When the UE sends a registration request message to the SGSN,the UE reports the registration processing type information to the SGSN.The SGSN identifies the registration processing type according to theinformation. Further, the SGSN performs the corresponding operationsaccording to the registration processing type to complete theregistration. The SGSN reports the registration processing type to theHSS. For the registration caused by handover, the network initiates abearer creation procedure to create resources in the 3GPP network usedby the UE in the source non-3GPP network. For initializationregistration, if the HSS stores the PDN GW address used by the UE in thenon-3GPP network, the HSS notifies the AAA server to cancel the UEregistration in the non-3GPP network. The AAA server notifies thenon-3GPP network to release the resource used by the UE. As illustratedin FIG. 8 , the process includes the following steps:

1. The UE accesses the non-3GPP AN through the non-3GPP GW and the PDNGW.

2. The non-3GPP network element sends an HO Command to the UE, notifyingthe UE to hand over to the 2G or 3G network; or the UE discovers the 2Gor 3G network and decides to initiate handover.

3. Before initiating registration into the 2G or 3G network, the UEidentifies the type of the registration. Afterward, the UE sends aregistration request message to the SGSN, and reports the registrationprocessing type to the SGSN.

The registration processing type may be reported in one of the followingways:

(1) An Attach Type IE is added in the Attach Request message. Forexample, the values of the Attach Type IE are 0 and 1. The value “0”corresponds to Normal Attach (also known as Initial Attach), andindicates that the Attach Request message is a normal Attach Requestmessage (also known as initial Attach Request message); and the value“1” corresponds to Handover Attach, and indicates that the AttachRequest message is caused by handover. Alternatively, the UE adds anindication bit in the Attach Request message to indicate that the AttachRequest message is caused by handover. The original Attach Requestmessage indicates a normal Attach Request message (also known as initialAttach Request message). The indication bit may be:

a) a Handover Indication IE;

b) a Cause IE. The UE sets the Cause IE to “Attach due to Handover”; or

c) an Attach Type IE. The UE sets this IE to “Handover Attach”.

(2) A new message is defined. For example, a new Handover Attach Requestmessage is defined. This message indicates an Attach Request messagecaused by handover. The old Attach Request message indicates a normalAttach Request message (also known as an initial Attach Requestmessage). In this way, the UE can send different Attach Request messagesto the network to indicate the corresponding registration processingtype information. Alternatively, a new message corresponding to thenormal Attach Request message (also known as initial Attach Requestmessage) is defined, and the original Attach Request message correspondsto the Attach Request message caused by handover. Alternatively, boththe Attach Request message caused by handover and the normal AttachRequest message (also known as initial Attach Request message) areredefined.

(3) An Update Type IE is added in the RAU request message. For example,the values of the Update Type IE are 0 and 1. The value “0” correspondsto Normal RAU (also known as Initial RAU), and indicates that the RAUrequest message is a normal RAU request message (also known as initialRAU request message); and the value “1” corresponds to Handover RAU, andindicates that the RAU request message is caused by handover.Alternatively, the UE adds an indication bit in the RAU request messageto indicate that the RAU request message is caused by handover. Theoriginal RAU request message indicates a normal RAU request message(also known as initial RAU request message). The indication bit may be:

a) a Handover Indication IE;

b) a Cause IE. The UE sets the Cause IE to “RAU due to Handover”; or

c) an Update Type IE. The UE sets this IE to “Handover RAU”.

(4) A new message is defined. For example, a new Handover RAU Requestmessage is defined. This message indicates an RAU request message causedby handover. The old RAU request message indicates a normal RAU requestmessage (also known as an initial RAU request message). In this way, theUE can send different RAU request messages to the network to indicatethe corresponding registration processing type information.Alternatively, a new message corresponding to the normal RAU requestmessage (also known as initial RAU request message) is defined, and theoriginal RAU request message corresponds to the RAU request messagecaused by handover. Alternatively, both the RAU request message causedby handover and the normal RAU request message (also known as initialRAU request message) are redefined.

4. An authentication procedure is performed between the UE, the SGSN,and the HSS. In this step, the SGSN may report the registrationprocessing type of the UE to the HSS. If the registration processingtype is a handover processing type, the HSS may provide the SGSN withthe PDN GW address used by the UE in the non-3GPP AN.

5. The SGSN sends an Update Location message to the HSS, and registersthe address of the SGSN into the HSS. In this step, the SGSN may reportthe registration processing type of the UE to the HSS.

6. The HSS inserts the subscriber data into the SGSN.

7. The HSS returns an Update Location Ack message to the SGSN. In thisstep, the HSS may provide the SGSN with the PDN GW address used by theUE in the non-3GPP AN. In the UE registration process, if the HSSidentifies the UE registration processing type (for example, the HSSfinds that it stores the PDN GW address used by the UE in the non-3GPPAN, the HSS determines that the UE registration processing type isregistration caused by handover. Otherwise, the HSS determines that theUE registration processing type is a normal registration processingtype), the HSS adds an indication bit into the message to notify SGSN ofthe UE registration processing type information. The indication bit maybe:

a) a Handover Indication IE. If the UE registration processing type isregistration caused by handover, the HSS adds a Handover Indication IE.For a normal registration processing type, the HSS does not add this IE;

b) a Cause IE. For the registration caused by handover, the HSS sets theCause IE to “Update due to Handover Attach”. For normal registration,the HSS sets the Cause IE to “Update due to Initial Attach”, or does notadd the Cause IE; or

c) an Update Type IE. For the registration caused by handover, the HSSsets this IE to “Handover Attach”. For normal registration, the HSS setsthis IE to “Initial Attach”, or does not add this IE.

8. The SGSN identifies the processing type of the registration accordingto the registration processing type information reported by the UE orthe HSS.

Now the SGSN succeeds in distinguishing between different registrationprocessing types.

Further, if the processing type is normal registration, the SGSNperforms the normal registration procedure, and steps 11-16 areperformed.

If the processing type is registration caused by handover, the SGSNsends a Create Bearer Request message to the obtained PDN GW (namely,the current Gateway GPRS Supporting Node (GGSN)) address, requesting thenetwork to initiate bearer creation procedure. In this way, the serviceused by the UE in the non-3GPP network is re-created in the new accesssystem. The process proceeds to step 9.

9. If it is necessary to obtain the PCC rules applied by the user fromthe PCRF, the PDN GW sends a Request PCC Rules message to the PCRF toobtain the PCC rules applied by the user. The PCRF provides the PDN GWwith the PCC rules applied by the user.

10. The PDN GW initiates a network-initiate bearer creation procedure tocreate the bearer of the user, and then the process proceeds to step 16.

Steps 11-15 are the same as the counterpart in the first embodiment, andare not repeated here any further.

16. The SGSN returns an Attach Accept message or an RAU Accept messageto the UE.

Embodiment 3

The foregoing mechanism is also applicable to a trusted non-3GPP system.When the UE sends a registration request message to the non-3GPP GW, theUE reports the registration processing type information to the non-3GPPGW. The non-3GPP GW identifies the processing type of the registrationaccording to the information, and creates a bearer for the UE accordingto registration processing type to complete the registration. Thenon-3GPP GW reports the registration processing type to the AAA server,and the AAA server reports the registration processing type to the HSS.For the registration caused by handover, the network initiates a bearercreation procedure to create resources in the non-3GPP network used bythe UE in the source 3GPP network. For initialization registration, ifthe AAA server stores the PDN GW address used by the UE in the 3GPPnetwork, the AAA server notifies the HSS to cancel the UE registrationin the 3GPP network, and the AAA server notifies the PDN GW to releasethe resource used by the UE in the 3GPP network. As illustrated in FIG.9 , the process includes the following steps:

1. The UE accesses the 3GPP network through the serving GW and the PDNGW.

2. The MME or the SGSN sends an HO Command to the UE, notifying the UEto hand over to the non-3GPP network; or the UE discovers the non-3GPPnetwork and decides to initiate handover.

3. Before initiating registration into the non-3GPP network, the UEidentifies the type of the registration. Afterward, the UE sends anAccess Request message to the non-3GPP GW, and reports the registrationprocessing type to the non-3GPP GW.

The registration processing type may be reported in one of the followingways:

(1) An Access Type IE is added in the Access Request message. Forexample, the values of the Access Type IE are 0 and 1. The value “0”corresponds to Normal Access (also known as Initial Access), andindicates that the Access Request message is a normal Access Requestmessage (also known as initial Access Request message); and the value“1” corresponds to Handover Access, and indicates that the AccessRequest message is caused by handover. Alternatively, the UE adds anindication bit in the Access Request message to indicate that the AccessRequest message is caused by handover. The original Access Requestmessage indicates a normal Access Request message (also known as initialAccess Request message). The indication bit may be:

a) a Handover Indication IE;

b) a Cause IE. The UE sets the Cause IE to “Access due to Handover”; or

c) an Access Type IE. The UE sets this IE to “Handover Access”.

(2) A new message is defined. For example, a new Handover Access Requestmessage is defined. This message indicates an Access Request messagecaused by handover. The old Access Request message indicates a normalAccess Request message (also known as an initial Access Requestmessage). In this way, the UE can send different Access Request messagesto the network to indicate the corresponding registration processingtype information. Alternatively, a new message corresponding to thenormal Access Request message (also known as initial Access Requestmessage) is defined, and the original Access Request message correspondsto the Access Request message caused by handover. Alternatively, boththe Access Request message caused by handover and the normal AccessRequest message (also known as initial Access Request message) areredefined.

4. An authentication procedure is performed between the UE, the non-3GPPGW, the AAA server, and the HSS. In this step, the UE may report theregistration processing type to the non-3GPP GW. The UE puts an AccessType cell in the message of the authentication procedure. For example,the values of the Access Type IE are 0 and 1. The value “0” correspondsto Normal Access (also known as Initial Access), and indicates that theAccess Request message is a normal Access Request message (also known asinitial Access Request message); and the value “1” corresponds toHandover Access, and indicates that the Access Request message is causedby handover.

Alternatively, the UE puts an Attach Type cell in the message of theauthentication procedure. For example, the values of the Attach Type IEare 0 and 1. The value “0” corresponds to Normal Attach (also known asInitial Attach), and indicates that the registration processing type ofthe UE is normal registration (also known as initial registration); andthe value “1” corresponds to Handover Attach, and indicates that theregistration processing type of the UE is registration caused byhandover.

Alternatively, the UE adds an indication bit in the message of theauthentication procedure to indicate that the registration processingtype of the UE is registration caused by handover. The original messageof the authentication procedure indicates normal registration (alsoknown as initial registration). The indication bit may be:

a) a Handover Indication IE;

b) a Cause IE. The UE sets the Cause IE to “Attach due to Handover”; or

c) an Attach Type IE. The UE sets this IE to “Handover Attach”.

In this step, the non-3GPP GW reports the registration processing typeof the UE to the AAA server.

In the UE registration process, if the AAA server identifies the UEregistration processing type (for example, the AAA server finds that itstores the PDN GW address used by the UE in the 3GPP AN, the AAA serverdetermines that the UE registration processing type is registrationcaused by handover. Otherwise, the AAA server determines that the UEregistration processing type is a normal registration processing type),the AAA server adds an indication bit in the message to notify theregistration processing type information to non-3GPP GW. The indicationbit may be:

a) a Handover Indication IE. If the UE registration processing type isregistration caused by handover, the AAA server adds a HandoverIndication IE. For a normal registration processing type, the AAA serverdoes not add this IE;

b) a Cause IE. For the registration caused by handover, the AAA serversets the Cause IE to “Update due to Handover Attach”. For normalregistration, the AAA server sets the Cause IE to “Update due to InitialAttach”, or does not add the Cause IE; or

c) an Update Type IE. For the registration caused by handover, the AAAserver sets this IE to “Handover Attach”. For normal registration, theAAA server sets this IE to “Initial Attach”, or does not add this IE.

5. The non-3GPP GW identifies the processing type of the registrationaccording to the registration processing type information reported bythe UE.

Now the non-3GPP GW succeeds in distinguishing between differentregistration processing types.

Further, if the processing type is normal access, the non-3GPP GWperforms the normal access procedure, and steps 7-13 are performed.

If the processing type is access caused by handover, the non-3GPP GWsends a Request PCC Rules message to the PCRF to obtain the PCC rulesapplied by the user. The PCRF provides the non-3GPP GW with the PCCrules applied by the user, and then the process proceeds to step 6.

6. The non-3GPP GW initiates a network-initiate bearer creationprocedure to create the bearer of the user, and then the processproceeds to step 13.

7. If the UE registration processing type is normal registration and theAAA server stores the registered PDN GW addresses, and if such PDN GWaddresses are the PDN GW addresses used by the UE when the UE accessesthe 3GPP AN and are registered into the AAA server through the HSS, theAAA server sends a Cancel Register message to the PDN GW, requesting tocancel the UE registration in the 3GPP AN. The PDN GW returns a CancelRegister Ack message to the AAA server.

8. If the interface protocol between the PDN GW and the serving GW is aPMIP, the PDN GW sends a Binding Revocation Indication message to theserving GW to cancel the PMIP binding between the serving GW and the PDNGW. The serving GW returns a Binding Revocation Acknowledge message tothe PDN GW.

9. After receiving the Binding Revocation Indication message, theserving GW initiates a resource release procedure to release theresource used by the UE in the 3GPP AN.

10. If the interface protocol between the PDN GW and the serving GW is aGPRS Tunneling Protocol (GTP), the PDN GW initiates a resource releaseprocedure to release the resource used by the UE in the 3GPP AN.

11. A session abort procedure is performed between the PDN GW and thePCRF, and the PCRF is notified to release the PCC rules applied by theUE in the 3GPP AN.

12. The AAA server sends a Cancel Register message to the HSS to cancelthe UE registration in the HSS. The HSS returns a Cancel Register Ackmessage to the AAA server.

13. The non-3GPP GW returns an Access Accept message to the UE.

Embodiment 4

The foregoing mechanism is also applicable to a trusted non-3GPP system.When the UE sends a registration request message to the non-3GPP GW, theUE reports the registration processing type information to the non-3GPPGW. The non-3GPP GW identifies the processing type of the registrationaccording to the information, and creates a bearer for the UE accordingto registration processing type to complete the registration. Thenon-3GPP GW reports the registration processing type to the AAA server,and the AAA server reports the registration processing type to the HSS.For the registration caused by handover, the network initiates a bearercreation procedure to create resources in the non-3GPP network used bythe UE in the source 3GPP network. For initialization registration, ifthe AAA server stores the PDN GW address used by the UE in the 3GPPnetwork, the AAA server notifies the HSS to cancel the UE registrationin the 3GPP network, and the HSS notifies the MME/SGSN to release theresource used by the UE in the 3GPP network. As illustrated in FIG. 10 ,the process includes the following steps:

Steps 1-6 are the same as the counterpart in the third embodiment, andare not repeated here any further.

7. If the UE registration processing type is normal registration and theAAA server stores the registered PDN GW addresses, and if such PDN GWaddresses are the PDN GW addresses used by the UE when the UE accessesthe 3GPP AN and are registered into the AAA server through the HSS, theAAA server sends a Cancel Register message to the HSS, requesting tocancel the UE registration in the HSS. The HSS returns a Cancel RegisterAck message to the AAA server.

8. The HSS sends a Cancel Location message to the MME/SGSN. The MME/SGSNreturns a Cancel Location Ack message to the HSS.

9. The MME/SGSN separates the UE to release the resource used by the UEin the 3GPP AN.

10. A session abort procedure is performed between the PDN GW and thePCRF, and the PCRF is notified to release the PCC rules applied by theUE in the 3GPP AN.

11. The non-3GPP GW returns an Access Accept message to the UE.

Embodiment 5

The foregoing mechanism is also applicable to an untrusted non-3GPPsystem. When the UE sends an access authentication request orIKEv2/IPsec SA creation request message to an Evolved Packet DataGateway (ePDG, a type of non-3GPP GW), the UE reports the registrationprocessing type information to the ePDG. The ePDG identifies theregistration processing type according to the information, creates abearer for the UE according to the registration processing type, andcompletes the registration. The ePDG reports the registration processingtype to the AAA server, and the AAA server reports the registrationprocessing type to the HSS. For the registration caused by handover, thenetwork initiates a bearer creation procedure to create resources in thenon-3GPP network used by the UE in the source 3GPP network. Forinitialization registration, if the AAA server stores the PDN GW addressused by the UE in the 3GPP network, the AAA server notifies the HSS tocancel the UE registration in the 3GPP network, and the AAA servernotifies the PDN GW to release the resource used by the UE in the 3GPPnetwork. As illustrated in FIG. 11 , the process includes the followingsteps:

1. The UE accesses the 3GPP AN through the serving GW and the PDN GW.

2. The MME or the SGSN sends an HO Command to the UE, notifying the UEto hand over to the non-3GPP network; or the UE discovers the non-3GPPnetwork and decides to initiate handover.

3. An authentication procedure is performed between the UE, ePDG AAAserver, and HSS. In this step, the UE may report the registrationprocessing type of the UE to the ePDG. The UE puts an Access Type cellin the message of the access authentication procedure. For example, thevalues of the Access Type IE are 0 and 1. The value “0” corresponds toNormal Access (also known as Initial Access), and indicates that theAccess Request message is a normal Access Request message (also known asinitial Access Request message); and the value “1” corresponds toHandover Access, and indicates that the Access Request message is causedby handover.

Alternatively, the UE puts an Attach Type IE in the message of theaccess authentication procedure. For example, the values of the AttachType IE are 0 and 1. The value “0” corresponds to Normal Attach (alsoknown as Initial Attach), and indicates that the registration processingtype of the UE is normal registration (also known as initialregistration); and the value “1” corresponds to Handover Attach, andindicates that the registration processing type of the UE isregistration caused by handover.

Alternatively, the UE adds an indication bit in the message of theaccess authentication procedure to indicate that the registrationprocessing type of the UE is registration caused by handover. Theoriginal message of the access authentication procedure indicates normalregistration (also known as initial registration). The indication bitmay be:

a) a Handover Indication IE;

b) a Cause IE. The UE sets the Cause IE to “Attach due to Handover”; or

c) an Attach Type IE. The UE sets this IE to “Handover Attach”.

In this step, the ePDG may report the registration processing type ofthe UE to the AAA server, and the AAA server reports the registrationprocessing type of the UE to the HSS.

In the UE registration process, if the AAA server identifies the UEregistration processing type (for example, the AAA server finds that itstores the PDN GW address used by the UE in the 3GPP AN, the AAA serverdetermines that the UE registration processing type is registrationcaused by handover. Otherwise, the AAA server determines that the UEregistration processing type is a normal registration processing type),the AAA server adds an indication bit in the message to notify theregistration processing type information to ePDG. The indication bit maybe:

a) a Handover Indication IE. If the UE registration processing type isregistration caused by handover, the AAA server adds a HandoverIndication IE. For a normal registration processing type, the AAA serverdoes not add this IE;

b) a Cause IE. For the registration caused by handover, the AAA serversets the Cause IE to “Update due to Handover Attach”. For normalregistration, the AAA server sets the Cause IE to “Update due to InitialAttach”, or does not add the Cause IE; or

c) an Update Type IE. For the registration caused by handover, the AAAserver sets this IE to “Handover Attach”. For normal registration, theAAA server sets this IE to “Initial Attach”, or does not add this IE.

4. An IKEv2/IPSec SA creation procedure is performed between the UE,ePDG and AAA server. In this step, the UE may report the registrationprocessing type of the UE to the ePDG. The UE puts the Access Type IE orthe Attach Type IE in the message of the IKEv2/IPSec SA creationprocedure to indicate the registration processing type of the UE.Alternatively, the UE adds an indication bit in the message of theIKEv2/IPSec SA creation procedure to indicate that the registrationprocessing type of the UE is registration caused by handover. Theoriginal message of the IKEv2/IPSec SA creation procedure indicatesnormal registration (also known as initial registration). The indicationbit may be:

a) a Handover Indication IE;

b) a Cause IE. The UE sets the Cause IE to “Access due to Handover”; or

c) an Access Type IE. The UE sets this IE to “Handover Access”.

In this step, the ePDG may report the registration processing type ofthe UE to the AAA server, and the AAA server reports the registrationprocessing type of the UE to the HSS.

5. The ePDG identifies the processing type of the registration accordingto the registration processing type information reported by the UE.

Now the ePDG succeeds in distinguishing between different registrationprocessing types.

Further, if the processing type is normal access, the ePDG performs thenormal access procedure, and steps 7-13 are performed.

If the processing type is access caused by handover, the ePDG sends aRequest PCC Rules message to the PCRF to obtain the PCC rules applied bythe user. The PCRF provides the non-3GPP GW with the PCC rules appliedby the user, and then the process proceeds to step 6.

6. The ePDG initiates a network-initiate bearer creation procedure tocreate the bearer of the user, and then the process proceeds to step 13.

Steps 7-13 are the same as the counterpart in the third embodiment, andare not repeated here any further.

To sum up, in the embodiments of the present disclosure, the UE reportsthe registration processing type information to the network duringregistering into the network. Therefore, the network distinguishesbetween different registration processing types accordingly.

Further, the network may perform the corresponding procedure accordingto the identified processing type. Moreover, a mode of the UE reportingthe registration processing type information by adding an IE or defininga new message is disclosed in an embodiment of the present disclosure.

Further, in addition to the Initial Attach and the Handover Attachprocessing types mentioned above, the registration processing typesreported by the UE, HSS, and AAA server in this embodiment may includeother registration processing types such as Pre-Registration (namely,the UE pre-registers into the target access network), Idle Mode Handover(namely, the UE hands over in the idle mode), and Active Mode Handover(namely, the UE hands over in the active mode). For a multi-mode ordual-mode UE (namely, the UE can access multiple networkssimultaneously), possible registration processing types include: PowerOn Attach (namely, the UE is powered on), Normal Attach (namely, the UEaccesses the network normally), Handover Attach (namely, the UE performshandover). This embodiment does not restrict the value of theregistration processing type. Other registration processing types aredescribed below, taking the Idle Mode Handover and the Active ModeHandover as examples:

Embodiment 6

When the UE hands over from an HRPD network to an E-UTRAN network in theactive mode, the MME obtains the handover processing type of the UE. Ifdetermining that the handover processing type is handover of the UE inthe active mode, the MME notifies the eNodeB to create resource on theaccess network side and use the preliminary path handover mechanism. Asillustrated in FIG. 12 , the process includes the following steps:

1. The UE accesses the system at the HRPD network.

2. The UE or the HRPD Access Network (AN) decides to perform handover tothe 3GPP network.

3. The UE sends an Attach Request message to the MME through the HRPDnetwork. The MME obtains the processing type information. The MME mayobtain the processing type information in one of the following ways:

(1) The UE reports the processing type information: The Attach Requestmessage sent by the UE to the MME indicates whether the Attach procedureis handover in the idle state or handover in the active state. Thespecific mode of notifying the processing type may be:

✓ The UE adds an Attach Type IE in the Attach Request message toindicate the MME the handover processing type. Different values of theAttach Type indicate different processing types:

0 indicates Idle Mode Handover (handover in the idle mode); and

1 indicates Active Mode Handover (handover in the active mode).

✓ The UE adds a Cause IE in the Attach Request message to indicate thecause for the Attach Request message. The UE may set the following Causevalues:

Idle Mode Handover: This cause value indicates that the Attach Requestis caused by handover in the idle state; and

Active Mode Handover: This cause value indicates that the Attach Requestis caused by handover in the active state.

✓ The UE adds a UE State IE in the Attach Request message to report thestate of the UE. According to the state of the UE, the MME knows whetherthe UE hands over in the idle state or in the active state. The UE mayset the following UE State values:

0: indicates that the UE is in the idle state; and

1: indicates that the UE is in the active state.

✓ When the UE hands over in the active state, the UE adds an “activeflag” IE in the Attach Request message to indicate the need of creatingbearer on the access network side; and when the UE hands over in theidle state, the UE adds no “active flag” cell into the Attach Requestmessage to indicate no need of creating bearer on the access networkside. Alternatively, when the UE hands over in the active state, the UEsets the “active flag” IE to “True(1)” to indicate the need of creatingbearer on the access network side; and when the UE hands over in theidle state, the UE sets the “active flag” IE to “False(0)” to indicateno need of creating bearer on the access network side.

✓ When the UE hands over in the idle state, the UE adds an “Non-activeflag” IE in the Attach Request message to indicate no need of creatingbearer on the access network side; and when the UE hands over in theactive state, the UE adds no “Non-active flag” cell into the AttachRequest message to indicate the need of creating bearer on the accessnetwork side. Alternatively, when the UE hands over in the idle state,the UE sets the “Non-active flag” IE to “True(1)” to indicate no need ofcreating bearer on the access network side; and when the UE hands overin the active state, the UE sets the “Non-active flag” IE to “False(0)”to indicate the need of creating bearer on the access network side.

(2) The HRPD AN reports the processing type information: The S101interface message sent by the HRPD AN to the MME indicates whether theAttach procedure is handover in the idle state or handover in the activestate. The specific mode of notifying the processing type may be:

✓ The HRPD AN adds an Attach Type IE in the S101 interface message toindicate the MME the handover processing type Different values of theAttach Type indicate different processing types:

0 indicates Idle Mode Handover (handover in the idle mode); and

1 indicates Active Mode Handover (handover in the active mode).

✓ The HRPD AN adds a Cause IE in the S101 interface message to indicatethe cause for the Attach Request message. The HRPD AN may set thefollowing Cause values:

Idle Mode Handover: This cause value indicates that the Attach Requestis caused by handover in the idle state; and

Active Mode Handover: This cause value indicates that the Attach Requestis caused by handover in the active state.

✓ The HRPD AN adds a “UE State” IE into the S101 interface message toreport the state of the UE. According to the state of the UE, the MMEknows whether the UE hands over in the idle state or in the activestate. The UE may set the following UE State values:

0: indicates that the UE is in the idle state; and

1: indicates that the UE is in the active state.

✓ When the UE hands over in the active state, the HRPD AN adds an“active flag” IE in the S101 interface message to indicate the need ofcreating bearer on the access network side; and when the UE hands overin the idle state, the HRPD AN adds no “active flag” IE in the S101interface message to indicate no need of creating bearer on the accessnetwork side.

✓ When the UE hands over in the idle state, the HRPD AN include an“Non-active flag” IE in the S101 interface message to indicate no needof creating bearer on the access network side; and when the UE handsover in the active state, the HRPD AN adds no “Non-active flag” IE inthe S101 interface message to indicate the need of creating bearer onthe access network side.

4. The authentication procedure is performed.

5. The MME sends an Update Location message to the HSS to obtain thesubscriber data of the UE. The HSS returns the subscriber data of theUE, including the PDN GW address used by the UE.

6. The MME selects a serving GW, and sends a Create Default BearerRequest message to the serving GW. According to the information includedin the Attach Request message, the MME knows whether the UE hands overin the idle state or in the active state. If the MME finds that the UEhands over in the active state, the Create Default Bearer Requestmessage sent by the MME requests the serving GW to perform “preliminarypath handover”.

7. After receiving the Create Default Bearer Request message, theserving GW initiates a preliminary path handover procedure if findingthat the message requests the serving GW to perform “preliminary pathhandover”. The serving GW sends a Proxy BU message to the PDN GW. Afterreceiving the foregoing message, the PDN GW switches the user planeroute to the serving GW. That is, the PDN GW sends the received downlinkdata to the serving GW.

8. The serving GW returns a Create Default Bearer Response message tothe MME.

9. According to the information included in the Attach Request message,the MME knows whether the UE hands over in the idle state or in theactive state. If the MME finds that the UE hands over in the activestate, the MME sends a Relocation Request message to the eNodeB,requesting the eNodeB to create the resource on the access network side.The eNodeB finishes creating the resource on the access network side,and then returns a Relocation Request Acknowledge message to the MME.

10. The MME sends an Update Bearer Request message to the serving GW,requesting to update the downlink user plane path of the serving GW tothe eNodeB. The serving GW returns an Update Bearer Response message tothe MME.

11. If finding that the UE hands over in the active state, the MME sendsa S101 HO Command message to the HRPD AN. The message includes an AttachAccept message and an HO Command message.

12. The HRPD AN sends an HRPD AN L2 message to the UE. The messageincludes an Attach Accept message and an HO Command message.

13. The UE hands over to the E-UTRAN network, and sends an HO Completemessage to the eNodeB.

14. The eNodeB sends a Relocation Complete message to the MME,indicating that the UE has handed over to the E-UTRAN network.

It is worthy of attention that in this embodiment, step 6 may occurbefore, during or after step 9.

Embodiment 7

When the UE hands over from an HRPD network to an E-UTRAN network in theidle mode, the MME obtains the handover processing type of the UE. Ifdetermining that the handover processing type is handover in the idlemode, the MME neither notifies the eNodeB to create resource on theaccess network side nor uses the preliminary path handover mechanism. Asillustrated in FIG. 13 , the process includes the following steps:

1. The UE accesses the system at the HRPD network.

2. The UE or the HRPD Access Network (AN) decides to perform handover tothe 3GPP network.

3. The UE sends an Attach Request message to the MME through the HRPDnetwork. The handover processing type needs to be notified to the MME.The operations are the same as the counterpart in the sixth embodiment,and are not repeated here any further.

4. The authentication procedure is performed.

5. The MME sends an Update Location message to the HSS to obtain thesubscriber data of the UE. The HSS returns the subscriber data of theUE, including the PDN GW address used by the UE.

6. The MME selects a serving GW, and sends a Create Default BearerRequest message to the serving GW. According to the information includedin the Attach Request message, the MME knows whether the UE hands overin the idle state or in the active state. If the MME finds that the UEhands over in the idle state, the Create Default Bearer Request messagesent by the MME does not require the serving GW to perform “preliminarypath handover”. The serving GW returns a Create Default Bearer Responsemessage to the MME.

7. According to the information included in the Attach Request message,the MME knows whether the UE hands over in the idle state or in theactive state. If finding that the UE hands over in the idle state, theMME does not notify the eNodeB to create resource on the access networkside, but sends an Attach Accept message to the UE directly through theHRPD network.

8. The UE hands over to the E-UTRAN network, and sends a TAU Requestmessage to the MME, indicating that the UE has handed over to theE-UTRAN network.

9. After finding that the UE has handed over to the E-UTRAN network inthe idle state, the MME sends an Update Bearer Request message to theserving GW. The MME adds an indication bit in the Update Bearer Requestto require the serving GW to perform user plane path handover.

10. When the serving GW discovers the requirement of user plane pathhandover after receiving the Update Bearer Request message, the servingGW sends a Proxy BU message to the PDN GW to update the downlink userplane path of the PDN GW. The PDN GW switches the downlink user planepath to the serving GW, and then returns a Proxy BA message to theserving GW.

11. The serving GW returns an Update Bearer Response message to the MME.

12. The MME returns a TAU Accept message to the UE.

Embodiment 8

The method of notifying the handover processing type is also applicableto the normal handover from a non-3GPP network to a 3GPP network.Through an Attach Request message, the UE notifies the handoverprocessing type information to the MME or SGSN. According to thehandover processing type information, the MME or SGSN decides whether tonotify the access network to create the resource on the access networkside. As illustrated in FIG. 14 , the process includes the followingsteps:

1. The UE accesses the system at a non-3GPP network (such as WiMax orWLAN).

2. The UE decides to perform handover to the 3GPP network, and initiatesa handover procedure.

3. The UE sends an Attach Request message to a network element of thecore network through a 3GPP AN. If the 3GPP AN is a GERAN/UTRAN, thenetwork element of the core network is SGSN; or, if the 3GPP AN is anE-UTRAN, the network element of the core network is MME. The AttachRequest message sent by the UE to the MME/SGSN indicates whether theAttach procedure is handover in the idle state or handover in the activestate. The MME/SGSN obtains the processing type information. Thespecific mode of notifying the processing type may be:

✓ The UE adds an Attach Type IE in the Attach Request message toindicate the processing type of the MME/SGSN handover. Different valuesof the Attach Type indicate different processing types:

0 indicates Idle Mode Handover (handover in the idle mode); or

1 indicates Active Mode Handover (handover in the active mode).

✓ The UE adds a Cause IE in the Attach Request message to indicate thecause for the Attach Request message. The UE may set the following Causevalues:

Idle Mode Handover: This cause value indicates that the Attach Requestis caused by handover in the idle state; and

Active Mode Handover: This cause value indicates that the Attach Requestis caused by handover in the active state.

✓ The UE adds a “UE State” IE in the Attach Request message to reportthe state of the UE. According to the state of the UE, the MME/SGSNknows whether the UE hands over in the idle state or in the activestate. The UE may set the following UE State values:

0: indicates that the UE is in the idle state; or

1: indicates that the UE is in the active state.

✓ When the UE hands over in the active state, the UE adds an “activeflag” IE in the Attach Request message to indicate the need of creatingbearer on the access network side; and when the UE hands over in theidle state, the UE adds no “active flag” IE in the Attach Requestmessage to indicate no need of creating bearer on the access networkside. Alternatively, when the UE hands over in the active state, the UEsets the “active flag” IE to “True(1)” to indicate the need of creatingbearer on the access network side; and when the UE hands over in theidle state, the UE sets the “active flag” IE to “False(0)” to indicateno need of creating bearer on the access network side.

✓ When the UE hands over in the idle state, the UE adds an “Non-activeflag” IE in the Attach Request message to indicate no need of creatingbearer on the access network side; and when the UE hands over in theactive state, the UE adds no “Non-active flag” IE in the Attach Requestmessage to indicate the need of creating bearer on the access networkside. Alternatively, when the UE hands over in the idle state, the UEsets the “Non-active flag” IE to “True(1)” to indicate no need ofcreating bearer on the access network side; and when the UE hands overin the active state, the UE sets the “Non-active flag” IE to “False(0)”to indicate the need of creating bearer on the access network side.

4. The authentication procedure is performed.

5. The MME/SGSN sends an Update Location message to the HSS to obtainthe subscriber data of the UE. The HSS returns the subscriber data ofthe UE, including the PDN GW address used by the UE.

6. The MME/SGSN selects a serving GW, and sends a Create Default BearerRequest message to the serving GW.

7. The serving GW sends a Proxy BU message to the PDN GW to update thedownlink user plane path of the PDN GW. The PDN GW switches the downlinkuser plane path to the serving GW, and then returns a Proxy BA messageto the serving GW.

8. The serving GW returns a Create Default Bearer Response message tothe MME/SGSN.

9. According to the information included in the Attach Request message,the MME/SGSN knows whether the UE hands over in the idle state or in theactive state. If the MME/SGSN finds that the UE hands over in the activestate, steps 9-12 are performed. If the MME/SGSN finds that the UE handsover in the idle state, steps 13-14 are performed.

The MME/SGSN sends an Initial Context Setup Request message to the 3GPPAN, requesting the 3GPP AN to create resource on the access networkside. The message includes an Attach Accept message.

10. Radio bearer is created between the 3GPP AN and the UE.

11. The 3GPP AN returns an Initial Context Setup Complete message to theMME/SGSN. This message also includes the Attach Complete message.

12. The MME/SGSN sends an Update Bearer Request message to the servingGW, requesting to update the downlink user plane path to the eNodeB. Theserving GW updates the downlink user plane path to the 3GPP AN, and thenreturns an Update Bearer Response message to the MME/SGSN.

13. If the MME/SGSN finds that the UE hands over in the idle state, theMME/SGSN sends an Attach Accept message to the UE.

14. The UE returns an Attach Complete message to the MME/SGSN.

Embodiment 9

When the UE sends a registration request message to the non-3GPP GW, theUE reports the registration processing type information to the non-3GPPGW. The non-3GPP GW identifies the processing type of the registrationaccording to the information, and creates bearer for the UE according toregistration processing type to complete the registration. The non-3GPPGW reports the registration processing type to the AAA server, and theAAA server reports the registration processing type to the HSS. For theregistration caused by handover, the network initiates a bearer creationprocedure to create bearer in the non-3GPP network used by the UE in thesource 3GPP network. For initialization registration, if the HSS storesthe PDN GW address used by the UE in the 3GPP network, the HSS notifiesthe AAA server to cancel the UE registration in the 3GPP network, andthe AAA server notifies the PDN GW to release the resource used by theUE in the 3GPP network. As illustrated in FIG. 15 , the process includesthe following steps:

1. The UE accesses the 3GPP AN through the serving GW and the PDN GW.

2. The MME or the SGSN sends an HO Command to the UE, notifying the UEto hand over to the non-3GPP network; or the UE discovers the non-3GPPnetwork and decides to initiate handover.

3. Before initiating registration into the non-3GPP network, the UEidentifies the type of the registration. Afterward, the UE sends anAccess Request message to the non-3GPP GW, and reports the registrationprocessing type to the non-3GPP GW.

4. An authentication procedure is performed between the UE, the non-3GPPGW, the AAA server, and the HSS. In this step, the UE may report theregistration processing type to the non-3GPP GW.

In this step, the non-3GPP GW reports the registration processing typeto the AAA server and the HSS. If the registration processing type is ahandover processing type, the AAA server or HSS may provide the non-3GPPGW with the PDN GW address used by the UE in the 3GPP AN.

In the UE registration process, if the AAA server or HSS identifies theUE registration processing type (for example, the AAA server or HSSfinds that it stores the PDN GW address used by the UE in the 3GPP AN,the AAA server or HSS determines that the UE registration processingtype is registration caused by handover. Otherwise, the AAA server orHSS determines that the UE registration processing type is a normalregistration processing type), the AAA server or HSS adds an indicationbit in the message to notify the registration processing typeinformation to the non-3GPP GW. The indication bit may be:

a) a Handover Indication IE. If the UE registration processing type isregistration caused by handover, the AAA server or HSS adds a HandoverIndication IE. For a normal registration processing type, the AAA serveror HSS does not add this IE;

b) a Cause IE. For the registration caused by handover, the AAA serveror HSS sets the Cause IE to “Update due to Handover Attach”. For normalregistration, the AAA server or HSS sets the Cause IE to “Update due toInitial Attach”, or does not add the Cause IE; or

c) an Update Type IE. For the registration caused by handover, the AAAserver or HSS sets this IE to “Handover Attach”. For normalregistration, the AAA server or HSS sets this IE to “Initial Attach”, ordoes not add this IE.

5. The non-3GPP GW identifies the processing type of the registrationaccording to the registration processing type information reported bythe UE, AAA server, or HSS.

Now the non-3GPP GW succeeds in distinguishing between differentregistration processing types.

Further, if the processing type is normal access, the non-3GPP GWperforms the normal access procedure, and steps 7-13 are performed.

If the processing type is access caused by handover, the non-3GPP GWsends a Request PCC Rules message to the PCRF to obtain the PCC rulesapplied by the user. The PCRF provides the non-3GPP GW with the PCCrules applied by the user, and then the process proceeds to step 6.

6. The non-3GPP GW initiates a network-initiate bearer creationprocedure to create the bearer for the user, and then the processproceeds to step 13.

7. If the registration processing type is normal registration and theHSS stores the registered PDN GW addresses, and if such PDN GW addressesare the PDN GW addresses used by the UE when the UE accesses the 3GPPAN, the HSS sends a Cancel Register message to the AAA server,requesting to cancel the UE registration in the AAA server. The AAAserver returns a Cancel Register Ack message to the HSS.

8. The AAA server sends a Cancel Register message to the PDN GW,requesting to cancel the UE registration in the 3GPP AN. The PDN GWreturns a Cancel Register Ack message to the AAA server.

9. If the interface protocol between the PDN GW and the serving GW is aPMIP, the PDN GW sends a Binding Revocation Indication message to theserving GW to cancel the PMIP binding between the serving GW and the PDNGW. The serving GW returns a Binding Revocation Acknowledge message tothe PDN GW.

10. After receiving the Binding Revocation Indication message, theserving GW initiates a resource release procedure to release theresource used by the UE in the 3GPP AN.

11. If the interface protocol between the PDN GW and the serving GW is aGTP, the PDN GW initiates a resource release procedure to release theresource used by the UE in the 3GPP AN.

12. A session abort procedure is performed between the PDN GW and thePCRF, and the PCRF is notified to release the PCC rules applied by theUE in the 3GPP AN.

13. The non-3GPP GW returns an Access Accept message to the UE.

Embodiment 10

When the UE sends a registration request message to the non-3GPP GW, theUE reports the registration processing type information to the non-3GPPGW. The non-3GPP GW identifies the processing type of the registrationaccording to the information, and creates bearer for the UE according toregistration processing type to complete the registration. The non-3GPPGW reports the registration processing type to the AAA server, and theAAA server reports the registration processing type to the HSS. For theregistration caused by handover, the network initiates a bearer creationprocedure to create bearer in the non-3GPP network used by the UE in thesource 3GPP network. For initialization registration, if the HSS storesthe PDN GW address used by the UE in the 3GPP network, the HSS notifiesthe AAA server to cancel the UE registration in the 3GPP network, andthe HSS notifies the MME/SGSN to release the resource used by the UE inthe 3GPP network. As illustrated in FIG. 16 , the process includes thefollowing steps:

Steps 1-6 are the same as the counterpart in the ninth embodiment, andare not repeated here any further.

7. If the UE registration processing type is normal registration and theHSS stores the registered PDN GW addresses, and if such PDN GW addressesare the PDN GW addresses used by the UE when the UE accesses the 3GPPAN, the HSS sends a Cancel Register message to the AAA server,requesting to cancel the UE registration in the AAA server. The AAAserver returns a Cancel Register Ack message to the HSS.

8. The HSS sends a Cancel Location message to the MME/SGSN. The MME/SGSNreturns a Cancel Location Ack message to the HSS.

9. The MME/SGSN separates the UE to release the resource used by the UEin the 3GPP AN.

10. A session abort procedure is performed between the PDN GW and thePCRF, and the PCRF is notified to release the PCC rules applied by theUE in the 3GPP AN.

11. The non-3GPP GW returns an Access Accept message to the UE.

Embodiment 11

When the UE hands over from a non-3GPP network to a 3GPP network in theactive mode, the first network element of the 3GPP network obtains thehandover processing type. If determining that the handover processingtype is handover in the active mode, the first network element of the3GPP network notifies the PDN GW not to initiate the resource releaseprocedure in the source non-3GPP network, and notifies the serving GW tocreate a data forwarding tunnel between the serving GW and the non-3GPPGW. As illustrated in FIG. 17 , the process includes the followingsteps:

1. The UE accesses the system at the non-3GPP network.

2. The UE or the non-3GPP access network element (for an HRPD network,the non-3GPP access network element is an HRPD Radio Network Controller(RNC)) decides to perform handover to the 3GPP network.

3. Through the non-3GPP network, the UE sends an Attach Request messageto the first network element of the 3GPP network (for the E-UTRANnetwork, the first network element of the 3GPP network is an MME; forthe GERAN/UTRAN network, the first network element of the 3GPP networkis an SGSN). The first network element of the 3GPP network obtains theprocessing type information. The first network element of the 3GPPnetwork may obtain the processing type information in one of thefollowing ways:

(1) The UE reports the processing type information: The Attach Requestmessage sent by the UE to the first network element of the 3GPP networkindicates whether the Attach procedure is handover in the idle state orhandover in the active state. The specific mode of notifying theprocessing type may be:

✓ The UE adds an Attach Type IE into the Attach Request message toindicate the handover processing type to the MME. Different values ofthe Attach Type indicate different processing types:

0 indicates Idle Mode Handover (handover in the idle mode); or

1 indicates Active Mode Handover (handover in the active mode); or

For optimized handover or pre-registration in the active state, the UEsets the Attach Type IE in the Attach Request message to “OptimizedHandover” or “Pre-registration” or “Handover”. After receiving theAttach Type, the first network element of the 3GPP network believes thatthe Attach procedure is handover in the active state by default.

✓ The UE adds a Cause IE in the Attach Request message to indicate thecause for the Attach Request message. The UE may set the following Causevalues:

Idle Mode Handover: This cause value indicates that the Attach Requestis caused by handover in the idle state; or

Active Mode Handover: This cause value indicates that the Attach Requestis caused by handover in the active state.

✓ The UE adds a UE State” IE in the Attach Request message to report thestate of the UE. According to the state of the UE, the MME knows whetherthe UE hands over in the idle state or in the active state. The UE mayset the following UE State values:

0: indicates that the UE is in the idle state; or

1: indicates that the UE is in the active state.

✓ When the UE hands over in the active state, the UE adds an “activeflag” IE in the Attach Request message to indicate the need of creatingbearer on the access network side; and when the UE hands over in theidle state, the UE adds no “active flag” IE in the Attach Requestmessage to indicate no need of creating bearer on the access networkside. Alternatively, when the UE hands over in the active state, the UEsets the “active flag” IE to “True(1)” to indicate the need of creatingbearer on the access network side; and when the UE hands over in theidle state, the UE sets the “active flag” IE to “False(0)” to indicateno need of creating bearer on the access network side.

✓ When the UE hands over in the idle state, the UE adds an “Non-activeflag” IE in the Attach Request message to indicate no need of creatingbearer on the access network side; and when the UE hands over in theactive state, the UE adds no “Non-active flag” IE in the Attach Requestmessage to indicate the need of creating bearer on the access networkside. Alternatively, when the UE hands over in the idle state, the UEsets the “Non-active flag” IE to “True(1)” to indicate no need ofcreating bearer on the access network side; and when the UE hands overin the active state, the UE sets the “Non-active flag” IE to “False(0)”to indicate the need of creating bearer on the access network side.

(2) The non-3GPP access network element or the non-3GPP GW reports theprocessing type information: The non-3GPP access network element or thenon-3GPP GW sends an interface message to the first network element ofthe 3GPP network to indicate whether the Attach procedure is handover inthe idle state or handover in the active state. The specific mode ofnotifying the processing type may be:

✓ The non-3GPP access network element or the non-3GPP GW adds an AttachType IE into the interface message sent to the first network element ofthe 3GPP network to indicate the handover processing type. Differentvalues of the Attach Type indicate different processing types:

0 indicates Idle Mode Handover (handover in the idle mode); or

1 indicates Active Mode Handover (handover in the active mode); or

For optimized handover or pre-registration in the active state, thenon-3GPP access network element or the non-3GPP GW sets the Attach TypeIE to “Optimized Handover” or “Pre-registration” or “Handover”. Afterreceiving the Attach Type, the first network element of the 3GPP networkbelieves that the Attach procedure is handover in the active state bydefault.

✓ The non-3GPP access network element or the non-3GPP GW adds a Cause IEin the interface message sent to the first network element of the 3GPPnetwork to indicate the cause for the Attach Request message. Thenon-3GPP access network element or the non-3GPP GW may set the followingCause values:

Idle Mode Handover: This cause value indicates that the Attach Requestis caused by handover in the idle state; or

Active Mode Handover: This cause value indicates that the Attach Requestis caused by handover in the active state.

✓ The non-3GPP access network element or the non-3GPP GW adds a “UEState” IE in the interface message sent to the first network element ofthe 3GPP network to report the UE state. According to the state of theUE, the first network element of the 3GPP network knows whether the UEhands over in the idle state or in the active state. The UE may set thefollowing UE State values:

0: indicates that the UE is in the idle state; or

1: indicates that the UE is in the active state.

✓ When the UE hands over in the active state, the non-3GPP accessnetwork element or the non-3GPP GW adds an “active flag” IE in theinterface message sent to the first network element of the 3GPP networkto indicate the need of creating bearer on the access network side. Whenthe UE hands over in the idle state, the non-3GPP access network elementor the non-3GPP GW adds no “active flag” IE in the interface messagesent to the first network element of the 3GPP network to indicate noneed of creating bearer on the access network side.

✓ When the UE hands over in the idle state, the non-3GPP access networkelement or the non-3GPP GW adds a “Non-active flag” IE in the interfacemessage sent to the first network element of the 3GPP network toindicate no need of creating bearer on the access network side. When theUE hands over in the active state, the non-3GPP access network elementor the non-3GPP GW adds no “Non-active flag” IE into the interfacemessage sent to the first network element of the 3GPP network toindicate the need of creating bearer on the access network side.

4. The authentication procedure is performed.

5. The first network element of the 3GPP network sends an UpdateLocation message to the HSS to obtain the subscriber data of the UE. TheHSS returns the subscriber data of the UE, including the PDN GW addressused by the UE.

6. The first network element of the 3GPP network selects a serving GW,and sends a Create Default Bearer Request message to the serving GW.

7. If the interface protocol between the serving GW and the PDN GW is aGTP, the serving GW sends a Create Default Bearer Request message to thePDN GW. If the interface protocol between the serving GW and the PDN GWis a PMIP, the serving GW sends a Proxy BU message to the PDN GW. ThePDN GW returns a Create Default Bearer Response message or a Proxy BAmessage to the serving GW.

8. The serving GW returns a Create Default Bearer Response message tothe first network element of the 3GPP network.

9. If finding that the UE hands over in the active state, the firstnetwork element of the 3GPP network sends a Create Forwarding TunnelsRequest to the serving GW, requesting the serving GW to create aforwarding tunnel. The serving GW returns a Create Forwarding TunnelsResponse message to the first network element of the 3GPP network. Themessage includes the forwarding tunnel information (including a servingGW address and Generic Routing Encapsulation (GRE) Keys).

10. If finding that the UE hands over in the active state, the firstnetwork element of the 3GPP network sends an HO Command message to thenon-3GPP access network element or the non-3GPP GW. The message includesan Attach Accept message, an HO Command message, and forwarding tunnelinformation (including a serving GW address and GRE Keys).

11. After receiving the HO Command message, the non-3GPP access networkelement sends a Create Forwarding Tunnels Request message to thenon-3GPP GW, notifying the non-3GPP GW of the obtained forwarding tunnelinformation. The non-3GPP GW returns a Create Forwarding TunnelsResponse message to the non-3GPP access network element.

Subsequently, the non-3GPP GW forwards the received downlink data to theserving GW through the forwarding tunnel (including a serving GW addressand GRE keys).

12. The non-3GPP access network element or the non-3GPP GW sends an HOCommand message to the UE. The message includes an Attach Accept messageand an HO Command message.

13. The UE hands over to the 3GPP network, and sends an HO Completemessage to the 3GPP access network element.

14. The 3GPP access network element sends a Relocation Complete messageto the first network element of the 3GPP network, indicating that the UEhas handed over to the 3GPP network.

15. The first network element of the 3GPP network sends an Update BearerRequest message to the serving GW. If finding that the UE hands over inthe active state, the first network element of the 3GPP network adds anindication bit in the Update Bearer Request message to indicate the PDNGW not to initiate a resource release procedure to release the resourceused by the UE in the source non-3GPP AN. This indication bit may be:Optimized Handover Indication, Pre-registration Indication, or Resourcenot Release Indication. Specifically, the indication bit may be:

(1) an Update Type indication bit. The first network element on thenetwork side sets the Update Type indication bit to “Pre-registration”or “Optimized Handover”;

(2) a Cause value. The first network element on the network side setsthe Cause value to “Pre-registration”, “Optimized Handover” or “Resourcenot Release”; or

(3) a Pre-registration Indication, or Optimized Handover Indication, orResource not Release Indication.

16. If the interface protocol between the serving GW and the PDN GW isGTP, the serving GW sends an Update Bearer Request message to the PDNGW. If the interface protocol between the serving GW and the PDN GW isPMIP, the serving GW sends a Proxy BU message to the PDN GW. The servingGW adds an indication bit in the Update Bearer Request message or theProxy BU message to indicate the PDN GW not to initiate a resourcerelease procedure to release the resource used by the UE in the sourcenon-3GPP AN. This indication bit may be: Optimized Handover Indication,Pre-registration Indication, or Resource not Release Indication.Specifically, the indication bit may be:

(1) an Update Type indication bit, or a Binding Type indication bit. Theserving GW sets the Update Type indication bit or the Binding Typeindication bit to “Pre-registration” or “Optimized Handover”;

(2) a Cause value. The serving GW sets the Cause value to“Pre-registration”, “Optimized Handover”, or “Resource not Release”; or

(3) a Pre-registration Indication, or Optimized Handover Indication, orResource not Release Indication.

After receiving the foregoing message, the PDN GW does not initiate theresource release procedure to release the resource used by the UE in thesource non-3GPP AN (namely, the resource release procedure to releasethe resource used by the UE in the source non-3GPP AN is not triggeredby the PDN GW). The PDN GW returns an Update Bearer Response message ora Proxy BA message to the serving GW.

17. The serving GW returns an Update Bearer Response message to thefirst network element of the 3GPP network.

18. After receiving the Relocation Complete message from the eNodeB, thefirst network element of the 3GPP network returns an HO Complete messageto the non-3GPP access network element or the non-3GPP GW.

19. After receiving the HO Complete message from the first networkelement of the 3GPP network, the non-3GPP access network element or thenon-3GPP GW initiates a resource release procedure to release theresource in the source non-3GPP AN.

Note:

1. In this embodiment, step 6 may occur before, during or after step 9;and

2. This embodiment does not limit the message in step 9 and step 11. Forexample, for the HRPD network, the message in step 11 may also be anA11-Registration Request message.

Embodiment 12

When the UE hands over from a 3GPP network to a non-3GPP network in theactive mode, the network element in the non-3GPP network obtains thehandover processing type. If determining that the handover processingtype is handover in the active mode, the network element in the non-3GPPnetwork creates access network resource and a data forwarding resource,and notifies the PDN GW not to initiate resource release procedure torelease the resource on the source side. As illustrated in FIG. 18 , theprocess includes the following steps:

1. The UE accesses the 3GPP network through the serving GW and the PDNGW.

2. Through the 3GPP network, the UE performs the Attach procedure andthe authentication procedure which are specific to the non-3GPP network.

3. Through the 3GPP network, the UE triggers a layer-3 Attach procedurein the non-3GPP network. The access network (for example, RNC in theHRPD network) or the non-3GPP GW (for example, PDSN in the HRPD network)in the non-3GPP network obtains the handover processing typeinformation. The access network or the non-3GPP GW in the non-3GPPnetwork obtains the handover processing type information in one of thefollowing ways:

(1) The UE reports the processing type information: The 65 message ofthe layer-3 Attach procedure sent by the UE to the access network or thenon-3GPP GW in the non-3GPP network indicates whether the procedure ishandover in the idle state or handover in the active state. The specificmode of notifying the processing type may be:

✓ The UE adds an Attach Type IE in the message of the layer-3 Attachprocedure sent to the access network or the non-3GPP GW in the non-3GPPnetwork, and this IE indicates the handover processing type. Differentvalues of the Attach Type indicate different processing types:

0 indicates Idle Mode Handover (handover UE in the idle mode); or

1 indicates Active Mode Handover (handover in the active mode); or

For optimized handover or pre-registration in the active state, the UEsets the Attach Type IE in the message of the layer-3 Attach procedureto “Optimized Handover”, or “Pre-registration”, or “Handover”. Afterreceiving the Attach Type, the access network or the non-3GPP GW in thenon-3GPP network believes that the layer-3 Attach procedure is handoverof the UE in the active state by default.

✓ The UE adds a Cause IE in the message of the layer-3 Attach procedureto indicate the cause for the message of the layer-3 Attach procedure.The UE may set the following Cause values:

Idle Mode Handover: This cause value indicates that the message of thelayer-3 Attach procedure is caused by handover in the idle state; or

Active Mode Handover: This cause value indicates that the message of thelayer-3 Attach procedure is caused by handover in the active state.

✓ The UE adds a “UE State” IE in the message of the layer-3 Attachprocedure message to report the state of the UE. According to the stateof the UE, the access network or the non-3GPP GW in the non-3GPP networkknows whether the UE hands over in the idle state or in the activestate. The UE may set the following UE State values:

0: indicates that the UE is in the idle state; or

1: indicates that the UE is in the active state.

✓ When the UE hands over in the active state, the UE adds an “activeflag” IE in the message of the layer-3 Attach procedure message toindicate the need of creating bearer on the access network side; andwhen the UE hands over in the idle state, the UE adds no “active flag”IE in the message of the layer-3 Attach procedure message to indicate noneed of creating bearer on the access network side. Alternatively, whenthe UE hands over in the active state, the UE sets the “active flag” IEto “True(1)” to indicate the need of creating bearer on the accessnetwork side; and when the UE hands over in the idle state, the UE setsthe “active flag” IE to “False(0)” to indicate no need of creatingbearer on the access network side.

✓ When the UE hands over in the idle state, the UE adds a “Non-activeflag” IE in the message of the layer-3 Attach procedure message toindicate no need of creating bearer on the access network side; and whenthe UE hands over in the active state, the UE adds no “Non-active flag”IE in the message of the layer-3 Attach procedure message to indicatethe need of creating bearer on the access network side. Alternatively,when the UE hands over in the idle state, the UE sets the “Non-activeflag” IE to “True(1)” to indicate no need of creating bearer on theaccess network side; and when the UE hands over in the active state, theUE sets the “Non-active flag” IE to “False(0)” to indicate the need ofcreating bearer on the access network side.

(2) The first network element of the 3GPP network reports the processingtype: The interface message sent by the first network element of the3GPP network to the access network or the non-3GPP GW in the non-3GPPnetwork indicates whether the layer-3 Attach procedure is handover inthe idle state or handover in the active state. The specific mode ofnotifying the processing type may be:

✓ The first network element of the 3GPP network adds an Attach Type IEin the interface message sent to the access network or the non-3GPP GWin the non-3GPP network. This IE indicates the handover processing type.Different values of the Attach Type indicate different processing types:

0 indicates Idle Mode Handover (handover in the idle mode); or

1 indicates Active Mode Handover (handover in the active mode).

For optimized handover or pre-registration of the UE in the activestate, the first network element of the 3GPP network sets the AttachType IE to “Optimized Handover”, or “Pre-registration”, or “Handover”.After receiving the Attach Type, the access network or the non-3GPP GWin the non-3GPP network believes that the layer-3 Attach procedure ishandover in the active state by default.

✓ The first network element of the 3GPP network adds a Cause IE in theinterface message sent to the access network or the non-3GPP GW in thenon-3GPP network to indicate the cause for the layer-3 Attach proceduremessage. The first network element of the 3GPP network may set thefollowing Cause values:

Idle Mode Handover: This cause value indicates that the message of thelayer-3 Attach procedure is caused by handover in the idle state; or

Active Mode Handover: This cause value indicates that the message of thelayer-3 Attach procedure is caused by handover in the active state.

✓ The first network element of the 3GPP network adds a UE State” IE inthe interface message sent to the access network or the non-3GPP GW inthe non-3GPP network to report the UE state. According to the state ofthe UE, the access network or the non-3GPP GW in the non-3GPP networkknows whether the UE hands over in the idle state or in the activestate. The UE may set the following UE State values:

0: indicates that the UE is in the idle state; or

1: indicates that the UE is in the active state.

✓ When the UE hands over in the active state, the first network elementof the 3GPP network adds an “active flag” IE in the interface messagesent to the access network or the non-3GPP GW in the non-3GPP network toindicate the need of creating bearer on the access network side. Whenthe UE hands over in the idle state, the first network element of the3GPP network adds no “active flag” IE in the interface message sent tothe access network or the non-3GPP GW in the non-3GPP network toindicate no need of creating bearer on the access network side.

✓ When the UE hands over in the idle state, the first network element ofthe 3GPP network adds a “Non-active flag” IE in the interface messagesent to the access network or the non-3GPP GW in the non-3GPP network toindicate no need of creating bearer on the access network side. When theUE hands over in the active state, the first network element of the 3GPPnetwork adds no “Non-active flag” IE in the interface message sent tothe access network or the non-3GPP GW in the non-3GPP network toindicate the need of creating bearer on the access network side.

It is worthy of attention that:

The access network or the non-3GPP GW in the non-3GPP network may alsoobtain the handover processing type information in step 2. The specificprocessing mode is the same as that in step 3.

4. If finding that the UE hands over in the active state, the non-3GPPAN sends a Create Forwarding Tunnels Request message to the non-3GPP GWto request data forwarding resources.

5. The non-3GPP GW returns a Create Forwarding Tunnels Response messageto the non-3GPP AN. The message includes the data forwarding tunnelinformation (for example, for the HRPD network, the data forwardingtunnel information is a PDSN address and a PDSN GRE key) of the non-3GPPGW.

6. If finding that the UE hands over in the active state, the non-3GPPGW sends a Create Resource Request message to the non-3GPP accessnetwork element, requesting to create resource on the access networkside. The non-3GPP access network element allocates the resource on theaccess network side, and returns a Create Resource Response message tothe non-3GPP GW.

7. If finding that the UE hands over in the active state, the non-3GPPaccess network element or the non-3GPP GW sends an HO Command message tothe first network element of the 3GPP network. The message includes thedata forwarding tunneling information of the non-3GPP GW.

8. After receiving the HO Command, the first network element of the 3GPPnetwork sends a Create Forwarding Tunnels Request message to the servingGW, requesting the serving GW to create data forwarding tunnel. Themessage includes the data forwarding tunnel information of the non-3GPPGW. The serving GW creates data forwarding tunnel, and returns a CreateForwarding Tunnels Response message to the first network element of the3GPP network.

9. The first network element of the 3GPP network sends a RelocationCommand message to the 3GPP access network element.

The 3GPP access network element forwards the received downlink datapacket to the serving GW, and the serving GW forwards the receivedpacket to the non-3GPP GW.

10. The 3GPP AN sends an HO Command message to the UE, requesting the UEto hand over to the non-3GPP network.

11. The UE hands over to the non-3GPP network, and sends an accessmessage to notify the network element in the non-3GPP network that theUE has handed over to the non-3GPP network. The specific access messagedepends on the non-3GPP network. For example, for an HRPD network, theaccess message is HRPD Traffic Channel Complete (TCC) message.

12. If the interface protocol between the non-3GPP GW and the PDN GW isPMIP, the non-3GPP GW sends a Proxy BU message to the PDN GW. If findingthat the UE hands over in the active state, the non-3GPP GW adds anindication bit in the Proxy BU message to indicate the PDN GW not toinitiate a resource release procedure to release the resource used bythe UE in the source 3GPP network. This indication bit may be: OptimizedHandover Indication, Pre-registration Indication, or Resource notRelease Indication. The specific processing mode of the indication bitis the same as that in the 11^(th) embodiment.

After receiving the foregoing message, the PDN GW does not initiate theresource release procedure to release the resource used by the UE in thesource 3GPP AN (namely, the resource release procedure to release theresource used by the UE in the source 3GPP AN is not triggered by thePDN GW). The PDN GW returns a Proxy BA message to the non-3GPP GW.

13. If the interface protocol between the UE and the PDN GW ishost-based mobility protocol such as Dual Stack MIPv6 (DSMIPv6), the UEsends a Binding Update (BU) message to the PDN GW. If finding that theUE hands over in the active state, the UE adds an indication bit in theBU message to indicate the PDN GW not to initiate a resource releaseprocedure to release the resource used by the UE in the source 3GPP AN.This indication bit may be: Optimized Handover Indication,Pre-registration Indication, or Resource not Release Indication. Thespecific processing mode of the indication bit is the same as that inthe 11^(th) embodiment.

After receiving the foregoing message, the PDN GW does not initiate theresource release procedure to release the resource used by the UE in thesource 3GPP AN (namely, the resource release procedure to release theresource used by the UE in the source 3GPP AN is not triggered by thePDN GW). The PDN GW returns a Binding Ack (BA) message to the UE.

14. The non-3GPP access network element or the non-3GPP GW sends an HOComplete message to the first network element of the 3GPP network.

15. After receiving the HO Complete message, the first network elementof the 3GPP network initiates the resource release procedure to releasethe resource used by the UE in the source 3GPP network.

It is worthy of attention that:

This embodiment does not limit the message in step 5 and step 8. Forexample, for the HRPD network, the message in step 5 may also be anAll-Registration Request message.

Embodiment 13

The method of notifying the handover processing type is also applicableto the normal handover from a 3GPP network to a non-3GPP network.Through an Access message of the non-3GPP network, the UE notifies thehandover processing type information to the non-3GPP GW. According tothe handover processing type, the non-3GPP GW decides whether to notifythe access network to create the resource on the access network side. Asillustrated in FIG. 19 , the process includes the following steps:

1. The UE accesses the 3GPP network through the serving GW and the PDNGW.

2. The UE hands over to the non-3GPP network, and performs the Attachprocedure and the authentication procedure which are specific to thenon-3GPP network.

3. Through the access network element of the non-3GPP network, the UEtriggers a layer-3 Attach procedure in the non-3GPP network. Thenon-3GPP GW (such as the PDSN in the HRPD network) obtains the handoverprocessing type information. The non-3GPP GW may obtain the processingtype information in the following way:

The UE reports the processing type information: The message of thelayer-3 Attach procedure sent by the UE to the non-3GPP GW indicateswhether the procedure is handover in the idle state or handover in theactive state. The specific mode of notifying the processing typeinformation is the same as that in the 6^(th) embodiment.

It is worthy of attention that:

The non-3GPP GW may also obtain the handover processing type informationin step 2. The specific processing mode is the same as that in step 3.

4. If finding that the UE hands over in the active state, the non-3GPPGW sends a Create Resource Request message to the non-3GPP accessnetwork element, requesting to create resource on the access networkside. The non-3GPP access network element allocates the resource on theaccess network side, and returns a Create Resource Response message tothe non-3GPP GW.

5. If the interface protocol between the non-3GPP GW and the PDN GW isPMIP, the non-3GPP GW sends a Proxy BU message to the PDN GW. The PDN GWreturns a Proxy BA message to the non-3GPP GW.

6. If the interface protocol between the UE and the PDN GW is ClientMobile Internet Protocol (CMIP), the UE sends a BU message to the PDNGW. The PDN GW returns a BA message to the UE.

7. The non-3GPP GW returns a layer-3 Attach Complete message to the UE.

To sum up, through the embodiments of the present disclosure, thenetwork-side network element is configured to perform discriminativeprocessing after obtaining the UE registration processing typeinformation, thus overcoming the inability of processingdiscriminatively according to different registration procedures in theprior art.

It is apparent that those skilled in the art can make modifications andvariations to the present disclosure without departing from the spiritand scope of the present disclosure. The present disclosure is intendedto cover the modifications and variations provided that they fall in thescope of protection defined by the following claims or theirequivalents.

What is claimed is:
 1. A registration processing method, comprising:identifying, by a user equipment (UE), a registration type whenregistering into a network; reporting, by the UE, a registrationprocessing type information corresponding to the identified registrationtype to a network-side network element during registering into thenetwork, wherein the registration processing type information reportedby the UE is an Type information element (IE) in an Attach Requestmessage, the values of which Type IE corresponds to Handover Attach andindicates that the Attach Request message is caused by handover, whenthe UE finds that the registration is caused by handover between a non3rd Generation Partnership Project (non-3GPP) network and a 3rdGeneration Partnership (3GPP) network.
 2. The method of claim 1, whereinthe method further comprises: for a registration caused by handover, thenetwork-side network element initiates a bearer creation procedure tocreate resources in a target Third Generation Partnership Project (3GPP)network used by the UE in a source non-3GPP network, or to createresources in a target non-3GPP network used by the UE in a source 3GPPnetwork.
 3. The method of claim 2, wherein the network-side networkelement is a Mobility Management Entity (MME), or a Serving GPRSSupporting Node (SGSN), the network-side network element initiates abearer creation procedure to create resources in a target 3GPP networkused by the UE in a source non-3GPP network comprises: obtaining, by theMME, a Packet Data Network Gateway (PDN GW) address used by the UE inthe source non-3GPP; sending a Create Bearer Request message to theobtained PDN GW address to request the network to initiate the bearercreation procedure.
 4. The method of claim 3, further comprising:sending, by the PDN GW, a Request Policy and Charging Control (PCC)Rules message to a Policy and Charging Rule Function (PCRF) to obtainthe PCC rules applied by the UE; providing, by the PCRF, the PDN GW withthe PCC rules applied by the UE.
 5. The method of claim 4, furthercomprising: initiating, by the PDN GW, a network-initiate bearercreation procedure to create the bearer of the UE.
 6. A User Equipment(UE), comprising: an identifying unit, configured to identify aregistration type when the UE initiates the registration; a registrationinitiating unit, configured to initiate registration and send aregistration triggering signal; and a reporting unit, configured toreceive the registration triggering signal from the registrationinitiating unit, and report processing type information duringregistering the UE into the network, wherein the processing typeinformation corresponds to the registration type identified by theidentifying unit, and the registration processing type information is anType information element (IE) in an Attach Request message, the valuesof which Type IE corresponds to Handover Attach and indicates that theAttach Request message is caused by handover, when the registration iscaused by handover between a non 3rd Generation Partnership Project(non-3GPP) network and a 3rd Generation Partnership (3GPP) network.
 7. Amethod, comprising: accessing, by a user equipment (UE), a non-3rdGeneration Partnership Project (non-3GPP) network; adding, by the UE, aninformation element (IE) to a request message for handover to a 3GPPnetwork; and sending, by the UE, the request message to a mobilitymanagement entity in the 3GPP network during a handover from thenon-3GPP network to the 3GPP network, wherein a value of the IE in therequest message indicates that the request message is caused byhandover.
 8. The method of claim 7, wherein the IE in the requestmessage indicates the 3GPP network to initiate a bearer creationprocedure to create in the 3GPP network, resources used by the UE in thenon-3GPP network.
 9. The method of claim 8, wherein the IE is a Type IE.10. The method of claim 7, wherein the 3GPP network is a GSM/EDGE radioaccess network (GERAN), a UMTS terrestrial radio access network (UTRAN),or an Evolved UMTS Terrestrial Radio Access Network (E-UTRAN), andwherein the non-3GPP network is a Wireless Local Area Network (WLAN) ora Worldwide Interoperability for Microwave Access (WiMAX) network. 11.The method of claim 7, wherein the request message is an access requestmessage.
 12. A communication device, comprising: a memory storinginstructions; and one or more processors in communication with thememory, wherein the one or more processors execute the instructions to:access a non-3rd Generation Partnership Project (non-3GPP) network; addan information element (IE) to a request message for handover to a 3GPPnetwork, and send the request message to a mobility management entity inthe 3GPP network during a handover from the non-3GPP network to the 3GPPnetwork, wherein a value of the IE in the request message indicates thatthe request message is caused by handover.
 13. The communication deviceof claim 12, wherein the communication device is a user equipment (UE).14. The communication device of claim 13, wherein the IE in the requestmessage indicates the 3GPP network to initiate a bearer creationprocedure to create in the 3GPP network, resources used by the UE in thenon-3GPP network.
 15. The communication device of claim 14, wherein theIE is a Type IE.
 16. The communication device of claim 13, wherein theUE initiates the handover from the non-3GPP network to the 3GPP network.17. The communication device of claim 13, wherein the UE receives ahandover command from the non-3GPP network.
 18. The communication deviceof claim 12, wherein the 3GPP network is a GSM/EDGE radio access network(GERAN), a UMTS terrestrial radio access network (UTRAN), or an EvolvedUMTS Terrestrial Radio Access Network (E-UTRAN), and wherein thenon-3GPP network is a Wireless Local Area Network (WLAN) or a WorldwideInteroperability for Microwave Access (WiMAX) network.
 19. Thecommunication device of claim 12, wherein the request message is anaccess request message.
 20. The communication device of claim 12,wherein the request message is an attach request message.
 21. The methodof claim 7, wherein the request message is an attach request message.22. The method of claim 7, further comprising: initiating, by the UE,the handover from the non-3GPP network to the 3GPP network.
 23. Themethod of claim 7, further comprising: receiving, by the UE, a handovercommand from the non-3GPP network.